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PROTEST UNDER 37 CFR 1.291(a) 

I am protesting against claim #1 in the following patent application that I 
became aware of just now. 

Details of pending patent at which protest is directed are mentioned in italics 
below 

United States Patent Application 20020083190 
Kind Code Al 
Kamiya, Satoshi ; etal June 27, 2002 

RFCELVED 

Apparatus and method for GFP frame transfer o 1 2003 

Abstract Technology Center 21 00 

The GFP frame transfer apparatus according to the present invention includes a 
GFP path frame formation unit (7, 8, 1 1, 13) that stores a label corresponding to 
a path ID defined to uniquely specify a path from the Ingress node to Egress 
node within a GFP network in a predetermined field off he extension header area 
of the GFP frame, stores packets to be trans ferred through the path in the 
payioad field of the GFP frame and forms a GFPpath frame. 



Inventors: Kamiya, Satoshi; (Tokyo, JP) ; Nishihara, Motoo; (T okyo, JP) 

Correspondence McGinn & Gibb, PLLC 

Name and Suite 200 

Address: 8321 Old Courthouse Road 

Vienna 

VA 

22182-3817 
US 

Serial No.: 024144 

Series Code: 10 

Filed: December 21, 2001 



Claim #1 in the above mentioned patent application titled "Apparatus and 
method for GFP frame transfer" cannot be patented because the ANSI GFP 
standard provides for the extension header to be used for carrying technology 
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specific data link information such as the virtual link Id (please see Technology Center 21 00 

T1X1 .5/2000-024R5, Generic Framing Procedure (GFP) under GFP 

extension header subheading relevant page included in this protest). The 

GFP standard specifically provides for the use of the virtual link Id (please 

see definition of the GFP extension header in the GFP standard- relevant 

page included in this protest). In the packet switching world the virtual link 

Id is also called by various names such as the virtual circuit Id, label, tag or 

virtual circuit number whose purpose is basically to identify a virtual link. 

The virtual link is a logical link created between a source and a destination 

node which for logical purposes can be treated as a link. The virtual link Id 

is a logical Id that identifies a particular circuit or virtual link or virtual 

circuit also called a label switched path. Each logical path or logical link is 

assigned this value when it is set up and it is known by many different 

names such as virtual call Id or virtual path ID or virtual circuit Id or label or 

tag, all meaning the same thing. It identifies a unique circuit that is set up 

using a path traversing many physical links within a packet network between 

a source and a destination. The GFP path frame formation unit for which a 

patent claim is sought is nothing but the optional extension header provided 

in the ANSI GFP standard . The GFP standard mentions that one of the 

several purposes of the extension header is to carry a virtual link Id which is 

simply another name for label claimed in the invention. Claim #1 of the 

aforesaid patent application usurps this use of GFP extension header from 

the American National Standard (currently in the public domain) to itself. 

The ability to carry a particular type of label and a particular arrangement of 
bits inside the optional GFP extension header for a particular type of 
switching may be patented but the ability to carry a label or virtual link Id 
cannot be patented because the standard specifically created the GFP 
extension header for the purposes of carrying such virtual link Id (aka label) 
information as mentioned in the standard itself. The standard only calls this 
as the virtual link Id. For the aforegoing reason claim #1 of the patent 
application should be denied. 
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Bit Transmission Order 
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Figure 7: GFP Type Field Format 



Defined Paylpad Type Identifiers, Extension Header Identifiers and Payload Identifiers are given in Tables 1, 
2 and 3. PTI is set to zero-(PTI=0) for GFP user frames conveying client data. PTI is set to one (PT1=1 ) for 
GFP user frames conveying far-end Client Signal Fail indications (clause 6.3.7). The Payload FCS is 
assumed present whenever PFI is set to one <PFI=1) and absent whenever PFI is set to zero {PFI=0). The 
interpretation pf the UPI field for PTI values different from zero or one is for further study.. 

6.1.2.1.2 Type HEG (tHEC) Field 

The two-octet Type Header Error Control field contains a CRCM6 generated sequence that protects the 
integrity of the contents- ot the Type_FielcLby enabling both singlerbit error correption aid multi-bit error 
detection, The tHEC generation process is defined In clause 6,3,4, 

6.1.2.1.3 GFP Extension Headers 



A O-to-60 octets extended field that supports technology specific data link headers such as virtual link 
identifiers, source/destination addresses, port numbers, Class of Service, extended- header error control, 
etc The length and format of the extension header is indicated by the-vakie of the Type field. 

6.1.2.1.4 Extension HEC (eHEC) Fieid 

The two-octet Extension Header Error Control field contains a CRC-16 generated sequence that protects the 
integrity of the contents of the extended headers, by enabling_botti single-bit error, correction and multi-bit 
error detection. The eHEC generation process is defined in clause 6.3.4, 

6.1.2.2 Paylpad Field 

The Payload field contains the framed PDU. This variable length field may include from 0 to 65 535 - X 
octets, whereXis. the- size of the-Paybad Header. Itmay include an optional Payload FCS field. The client 
user/control PDU is always transferred into the GFP Payload field as an octet-aligned packet stream. 



6.1.3 Payload Frame Check Sequence (FCS) Field 
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